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^ (57) Abstract: An integrated system provides patients with secure, real-time access to their Personal Health Record and an Enter- 
al prise Health Information System (PHR and EHIS, respectively). Access may be provided by way of the Internet and via a Personal 
^ Health Portal (PHP) web page. From the secure PHP web page, patients can view information created and maintained by their health 

care providers and their affiliated staff. The patients can also request services and information from their health care providers and 
Q affiliated staff, directly access EHIS-related services, such as scheduling an appointment, scheduling, paying a bill, enrolling in a 

class, completing insurance and other forms, and viewing information and Internet services that are relevant to their particular health 
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PATIENT HEALTH RECORD ACCESS SYSTEM 

Field of the Invention 

The present invention relates generally to health records management, 
5 and more particularly, to a system for providing a patient with access to the 
patient's health record^ 

Background of the Invention 

A variety of Internet-based systems for providing access to a patient's 

1 0 health record and related healthcare information have been proposed. Such 
Internet-based personal or patient medical records either provide patients 
access only to information that they enter and maintain themselves, or provide 
them with delayed and limited access to information contained in a separate 
healthcare information system from which patient health information must be 

15 abstracted and uploaded to a web server in regularly scheduled batch 

processes. A patient is unsure if the information they are viewing is the most 
up to date and complete. Apart from the ability to view selected portions of 
information or patient self-generated information, the proposed systems have 
not provided an effective forum to allow the patient to communicate with their 

20 health care providers. None of the proposed systems feature secured, real- 
time access to an integrated patient health record. 

Many attempts have previously been made to streamline the process of 
scheduling appointments for patients in the healthcare industry. From a 
healthcare organization's point of view, the most efficient method is to let 

25 patients schedule appointments themselves. However, until the advent of the 
Internet, this solution was not feasible. Now, the Internet has provided 
patients with direct access to an organization through the web, thereby 
opening up the possibility of self-scheduling. Nevertheless, self-scheduling 
over the Internet presents unique and interesting problems. For example, there 

30 are always security issues when dealing with medical information on the 

Internet. Also, if the system is not implemented properly, patients could abuse 
the system. Furthermore, Healthcare providers, such as doctors, nurses, and 
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surgeons often have concerns that they are losing control of their daily 
schedules if they allow patients to schedule their own appointments. 

The existing scheduling solutions are based on messaging or very 
restricted access. These solutions allow patients to enter some limited 
5 information concerning an appointment. Some examples are: (1) which 

provider the patient wants to see, (2) the day and time the patient wants to be 
seen, (3) some of the patient's insurance information, and (4) a few other types 
of information relevant to scheduling. 

After requests were submitted in the previous systems, workers at the 
clinics were then required to review each of the requests and contact every 
patient individually to inform him or her whether or not the request was 
granted. While this process is somewhat convenient for the patients, it does 
not automatically schedule appointments or immediately enter the data into 
the organization's system. Rather, it relies on human intervention to evaluate 
the requests and contact the patients when the decision to schedule the 
appointment has been made. 

Thus, there is a need for a patient health record access system that 
provides real-time communication between the patient and an integrated 
Patient Health Record (PHR) and an Enterprise Health Information System 
(EHIS). Such a system would provide patients with the most up-to-date 
information. Moreover, patients could avail themselves of electronic health- 
related services in real-time. Furthermore, a real-time, integrated PHR/EHIS 
system could provide efficiency, workflow flexibility and connectivity 
between patients and their health care providers and affiliated staff that are not 
available using previously disclosed systems. 

There is also demonstrated a need for healthcare organizations to allow 
the full scheduling of appointments over the Internet in an automated process 
that gives patients immediate results and eliminates the need for employees of 
the facility to review each request for an appointment. None of the previous 
systems satisfied this need. 
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Brief Description of the Drawings 

FIG. 1 is a system block diagram of a patient health record access 
system in accordance with a preferred embodiment of the invention. 

FIG. 2 is a flowchart illustrating operation of the system illustrated in 

5 FIG. 1. 

FIG. 3 is a flowchart illustrating operation of a content relevancy 
engine portion of the system illustrated in FIG. 1. 

FIG. 4 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for viewing of information by the patient. 

FIG. 5 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for processing messages. 

FIG. 6 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for accepting and recording information from a patient. 

FIG. 7 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for scheduling appointments in accordance with a preferred 
embodiment of the invention. 

FIG. 8 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for scheduling appointments in accordance with another preferred 
embodiment of the invention. 

FIG. 9 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for providing class enrollment. 

FIG. 10 is a flowchart illustrating operation of the system illustrated in 
FIG. 1 for paying bills. 

FIG. 1 1 is a flow chart representation of the path that the system would 
take when a patient attempted to schedule an appointment directly from the 
system. 

FIG. 12 is a flowchart that illustrates the process by which a user 
logged in to his Patient Health Portal (PHP) Web Page can schedule an 
appointment that has been pre-qualified. 

FIG. 13 is a flowchart illustrating the components and connections 
from the enterprise healthcare information management system through the 
Internet and on to the patient via a web page portal. 
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Detailed Description of the Preferred Embodiments 

An integrated system provides patients with secure, real-time access to 
their Personal Health Record and an Enterprise Health Information System 
(PHR and EHIS, respectively). Access may be provided by way of the 
5 Internet and via a Personal Health Portal (PHP) web page. From the secure 
PHP web page, patients can view information created and maintained by their 
health care providers and their affiliated staff. The patients can also request 
services and information from their health care providers and affiliated staff, 
directly access EHIS-related services, such as scheduling an appointment, 
10 paying a bill, enrolling in a class, completing insurance and other forms, and 
viewing information and Internet services that are relevant to their particular 
health status. 

In a preferred embodiment of the invention a patient health record data 
server, including a machine-readable media having a data structure containing 

1 5 patient-created data, is coupled by a communication network with a patient 
interface. The communication network may be the Internet and the patient 
interface may be a suitable Internet access device including a browser for 
supporting a personalized web page. A secure interface securely couples, in 
real-time, the patient health record server to an enterprise health record system 

20 for providing access by the patient to patient-related data retained within the 
enterprise health record system. Thus, the patient, via the patient interface, 
may access the patient health record server for manipulating the patient- 
created data and for accessing the patient-related data from the enterprise 
health record system. 

25 According to a preferred embodiment of the invention a system that 

enables a patient to use a pre-authorized or a user initiated scheduling process 
that utilizes hierarchically-layered rules. The system further provides dynamic 
feedback to self-schedule appointments with a user's preferred clinics and 
providers in a confidential and secure manner. 

30 The rules based ticketing system for self-scheduling provides healthcare 

clinics and providers the ability to manage and control patient appointment utilization. 
For several reasons, it is very desirable from a healthcare provider's perspective to 
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allow patients to schedule their own appointments. It is also desirable from a patient's 
perspective to be able to independently schedule their own appointments at their 
convenience through the Internet. A system according to the preferred embodiments 
of the invention satisfies the desires of both parties. 
5 While described in terms of several preferred embodiments, it will be 

appreciated that the invention is not limited in scope to the embodiments herein 
described. Many modifications, alterations and additions may be made without 
departing from the fair scope of the invention. 

Referring to FIG. 1 of the drawings, a patient access system 10 includes a 

1 0 Patient Health Record (PHR) data server 1 2 and an EHIS data server 1 4. The PHR 
data server 12 may be any suitable platform including processing, memory and data 
storage capability to perform the functions herein described. The PHR data server 12 
stores data entered by the patient within a data structure configured within the storage 
portion 26 of the PHR data server 12. A secure interface or EHIS queue 16 securely 

1 5 couples the PHR server 12 and the EHIS data server 14 for communication of data 
and information from the PHR data server 12 to the EHIS data server 14. The EHIS 
Queue 16 provides a real-time secure communication link for information moving 
from the PHR data server 12 to the EHIS data server 14. This queue is used to transfer 
information for secure messaging and self-service options. In response to information 

20 received from the PHP web page, the PHR data server 12 forwards information to the 
EHIS queue 16. Information in the EHIS queue 16 is then processed appropriately by 
the EHIS data server 14. 

While the specific configuration of the EHIS data server 14 is not particular to 
the structure and function of the present invention, preferably, the EHIS data server 

25 14 is a single data repository structured to support both the separation and the sharing 
of data. As such, the EHIS data server 14 may receive information from existing 
outpatient and inpatient data management systems via interfaces or from various 
integrated applications. The EHIS data server 14 may be configured to organize 
information into a consistent whole to provide a longitudinal patient record. For 

30 example, the EHIS data server 14 may be linked to manage all aspects of a patient's 
hospital health status and care and to support effective management of patient lists, 
results inquiry management, complete clinical documentation, physician order entry 
with decision support, nursing workflow and documentation, and discharge planning. 
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The EHIS data server 14 may farther be configured to support the inclusion of 
problem lists, order communications, results reporting, pharmacy management, quick 
documentation, clinical messaging and communication. Additionally, the EHIS data 
server 14 may be configured to manage referral information, up-to-date progress 
5 notes, lab results, discharge instructions, portions of a patient's record, and emergency 
summary cards. A suitable data management product that may be adapted as the 
EHIS data server 14 is the Epicenter® Enterprise Data Repository and related suite of 
products available from Epic System Corporation of Madison, Wisconsin. 

The PHR data server 12 includes a patient services application layer 22, a 

1 0 communication layer 24, a patient data manager 26 and a content relevancy engine 
28, all of which are suitably linked within an architecture for operation under the 
direction of the PHR data server 12. The patient data manager 26 includes suitable 
storage capability, such as magnetic, optical, or other storage technology, for storing 
patient-created data. The patient services application layer 22 and the communication 

15 layer 24 include routines for managing access and use of the patient-created data, as 
well as to provide patient services. The PHR data server 12 is further linked, by way 
of the content relevancy engine 28 to a source of generic data 30 and a source of 
news, educational and similar materials 32 via a secure connection 34, such as a 
Internet protocol secure (IPsec) connection or by a file transfer protocol (ftp) 

20 connection. 

A communication network 36 couples the PHR data server 12 to a patient 
interface 38. The communication network 36 may include the Internet 40 or other 
suitable data network, and the PHR data server 1 2 is linked to the Internet 40 by a 
web server 42 in a highly secure dual firewall configuration. In this arrangement, a 

25 primary fire wall 44 protects the web server 42 and a secondary fire wall 46 protects 
the PHR data server 12 and the EHIS data server 14 with a communication link 48 
coupling the communication network 36 to the PHR data server 12. 

In a preferred embodiment of the invention, a shadow server 50 is provided 
and maintains a copy of at least the patient-related data retained within the EHIS data 

30 server 14. A communication link 52 permits the copying of the patient-related data 
from the EHIS data server 14 to the shadow server 50, and a view access only 
communication link 56 couples the shadow server 50 to the communication network 
36, and hence to the patient interface 38.. This arrangement advantageously allows the 
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EHIS data server 14 to be highly available for EHIS systems operation. Alternatively, 
the communication network 36 may be directly linked to the EHIS data server 14. 

Patients access the system 10 by logging into the web server 42 via the patient 
interface 38. The patient interface 38 is preferably configured as a web page 
5 displayed within a web browser running on a suitable platform, and is further 
preferably configured as a personalized Personal Health Portal (PHP) web page 
providing the patient with patient-specific information and links to the features and 
services offered by the invention. The web server 42 may be any suitable web server 
platform containing routines for displaying the PHP web page and for managing 

10 online communication between a user logged in via an associated PHP web page and 
the PHR data server 12 and the EHIS data server 14. 

A user logging into the system via the PHP web page may or may not be an 
existing patient of the healthcare enterprise. For existing patient users, the PHR data 
server 12 may already contain a record for the patient and, as will be described, the 

1 5 user is provided access to the information contained in that record. Some existing 
patients and new patients may not have a record within the PHR data server 12. 
These patients will have at least two options for gaining access to the functionality of 
the system 10. First, the patient may fully register by providing appropriate 
identifying. The PHR data server 12 creates a patient record for the user. 

20 A patient may gain access without fully identifying himself or herself. The 

patient may enter patient data using a user name and identifying information that is 
anonymous in nature. Access for this "anonymous user" may be limited to predefined 
functionality. For example, the anonymous user may be permitted only to view 
information related to services provide by the healthcare enterprise, maybe able to 

25 create a record or patient created information within the PHR data server 1 2, may be 
able to ask questions of the healthcare enterprise and receive responses, and the like. 
The anonymous user, however, would not be permitted to make appointments or 
request specific services of the healthcare enterprise. Additionally, should the 
anonymous user become a patient of the healthcare enterprise, the PHR data server 12 

30 may use the anonymous user record to create a patient record within the PHR data 
server 12 without requiring the patient to reenter information. 

Operation and use of the system is described in more detail with reference to 
FIGS. 2-10. The flowcharts depicted in FIGS. 2-10 are linked and illustrate the 
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operation of the system 10 in accordance with a preferred embodiment of the 
invention. The alpha designations indicate the interconnections between the various 
flowcharts depicted in the figures. Turning to FIG. 2 depicted is a method 200 of 
providing access by a patient to the PHR data server 12 and the EHIS data server 14. 
5 The method 200 begins at step 202 where the patient accesses a public web page, 
such as an Internet service provider (ISP) home page, with a PHP web page option 
and selects the PHP web page option, step 204. At step 206, the user attempts to log 
into the PHP web page, which is provided by the web server 42, using a suitable 
authentication technology. The web server 42 executes the authentication routine at 

10 step 208, and a user authorization determination is made at step 210. If the user is not 
authorized, the user is returned to the public web page. If the user is authorized, the 
content relevancy engine 28 functions, step 212, as will be described in connection 
with FIG. 3, and at step 214, the web server 42 generates and displays the user's PHP 
web page on the patient interface 38. 

1 5 From the PHP web page, the user is provided a selection of links providing 

access to patient-relevant content, information from the patient's enterprise health 
record, and services associated with the enterprise health information system. If the 
user does not click on a link within a timeout period causes the web server 42, at step 
216, to log the user out and to return the user to the public page. 

20 At step 2 1 8 the user clicks a content link. Depending on the type of content 

selected by the user, step 220, if the item is stored directly in a content database or on 
the web server 42, at step 224 the content is displayed on the PHP web page. 
Otherwise, for items stored as URLs, at step 226 the data retrieval and display option 
associated with the link opens a separate browser page to display the content. 

25 In a preferred embodiment of the invention, the user may also select: a view 

option; a secure messaging option, an edit or add notes option; an online form; 
schedule a prequalified appointment option; schedule an appointment option; enroll in 
a class option; pay a bill option or log out, respectively, links associated with blocks 
228-244. 

30 Referring now to FIG. 3, the content relevancy engine 28 operates in 

accordance with a method 300 depicted therein. At step 302, the web server 42 
requests patient-related information from the Shadow Server 14 and caches it on the 
PHR data server 12. This data includes the user's sex, age, zip code, medical 
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problems and diagnoses (using ICD9 codes), procedures (using CPT codes) and 
medications (using GPI & NDC) as indicated at block 306. At step 304, another 
routine on the PHR data server 12 uses page layout specifications associated with the 
user's PHP web page, which may be specified by the system provider or may be user 
5 configurable, to determine what types of content to display, and how many items to 
display of each type. At step 308, for each type of content specified by the page 
layout, a routine within the content relevancy engine 28 compares the patient-related 
data to criteria in the content database. The content database is maintained on the 
PHR data server 1 2 and stores available content for display on the PHP web page 

10 with each record being categorized by display type, relevance factors, and effective 
dates as indicated at block 310. The content relevancy engine 28 at step 312 then 
determines if a content item is relevant based upon the cached patient-related 
information. At step 314, the content relevancy engine 28 then produces a ranked list 
of relevant content items, based on a number of matches between the content criteria 

15 and the patient-related information. Then, at step 316, the web server 42 builds the 
PHP web page according to the page layout (step 308), using the highest-ranking 
content items for each type of content. 

When the user selects a link associated with a view option, secure messaging 
option, or self-service option, the PHR data server 12 initiates a routine associated 

20 with the link. Link 228 in FIG. 2 initiates a view content routine 400 illustrated in 
FIG. 4. The system 10 advantageously permits viewing of a wide variety of 
information types including patient-created information stored within the PHR data 
server 12 and patient-related information stored within the EHIS data server 14. The 
patient-created data may be notes and comments relating to the user's health or 

25 requests for information. The patient-related information may be portions of the 
user's medical record and other information created by the health care professionals 
and staff. In the preferred embodiment illustrated in FIG. 4, the user may select to 
view a health summary, a medication list, lab results, health reminders, recent visit 
information, medical history, upcoming appointments, messages, immunization 

30 information, allergies information, current health issues, financial and insurance 

information, and records access by selecting an appropriate link associated with the 
requested information represented by blocks 402-424, respectively. Upon the user 
selecting the link, at step 426 the web server 42 receives the data request, and at step 
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428 initiates a routine to retrieve the requested information, either from the PHR data 
server 12 or the shadow server 50 (or EHIS data server 14 if so configured). At step 
430, the web server 42 updates the PHP web page with the new information. The 
web server 42 may retrieve the patient-related information from the shadow server 50 
5 in XML format as shown in block 432. Similarly, the web server 42 may retrieve the 
patient-created information from the PHR data server 12 in XML format, the patient- 
created information including user-entered notes or messages. 

The system 10 provides ability for the user to send and receive secure 
messages to the user's health care providers and administrators. Selecting the link 

10 230 in FIG. 2 initiates a secure messaging routine 500 illustrated in FIG. 5. The 
message types include a request for medical advice; a request for prescription 
renewal; a request for a referral; a customer service request; a request for a pre- 
qualified appointment and a request for an appointment, and the user selects the 
message type by selecting an appropriate link associated with the message type 

1 5 represented by blocks 502-5 12, respectively. Responsive to the user selecting one of 
the links 502-512, at step 514, the web server 42 creates a secure messaging form on 
the PHP web page for the selected message type. At step 516, the user enters the 
appropriate data and information into the message form. The user may cancel the 
message, step 518, and be returned to the previous PHP web page, or the user clicks 

20 send, step 522. The web server 42 forwards the information to the PHR server 12, 

step 524, and the PHR server 12 places the user's message in a queue for transmission 
to the EHIS data server 14. At step 528, the EHIS data server 14 receives the 
incoming message from the queue, and translates and routes the message to the 
appropriate destination, and at step 530, the web server 42 updates the PHP web page 

25 to reflect that the user's message has been sent. 

Selecting the link associated with block 232 (FIG. 2) allows the user to add 
notes to the patient-created information, and selecting the link associated with the 
block 234 allows the user to complete forms. Selecting either link 232 or 234 initiates 
a process 600 illustrated in FIG. 6. Additionally, the user may add information flags 

30 to the patient-created information and/or other information contained with the PHR 
server 12. The information flag identifies the flagged information and may provide 
read only access of the information to one or more of the user's health care 
professionals and staff. Coupled with the information flag, the PHR server 12 is 
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adapted to generate an alert that is communicated to the EHIS data server 14 
indicating the receipt of the flag. Appropriate messaging may also be generated and 
communicated to the one or more of the user's health care professionals and staff. 
If the user has selected the link associated with block 232, the web server 42 
5 creates an add/edit notes form and displays the form on the PHP web page. At step 
604, the user enters or edits the note text in an editing window. If the user selects 
cancel, step 606, the notes/edits are discarded and the web server 42 returns to the 
previously displayed PHP web page. If the user clicks to save changes, step 610, the 
web server 42 forwards the edited text to the PHR data server 12, step 612, and the 

1 0 PHR data server 1 2 updates the patients notes portion of the patient-created date 

stored within the PHR data server 12, step 614. The user notes may be unstructured 
information, such as unstructured text notes, or the notes may be structured 
information. As an example, to input structured information the user may be 
presented with a form seeking particular information, such as medications they are 

1 5 currently taking or procedures they have had or will have. The fields within the form 
may be linked to other data entries in the enterprise health record system, such as 
reference materials for the entered medication or procedure. Moreover, the 
information need not be clinical in nature, as described in foregoing examples, but 
may be administrative in nature, such as benefits information. 

20 A similar process occurs if the user has selected the link associated with block 

234. The web server 42 creates an online form, such as an insurance form or medical 
history form, and displays the form on the PHP web page, step 616. At step 618, the 
user enters information into the form in an editing window. If the user selects cancel, 
step 620, the information and form are discarded and the web server 42 returns to the 

25 previously displayed PHP web page, step 608. If the user clicks to save changes, step 
622, the web server 42 forwards the edited form to the PHR data server 12, step 624, 
and the PHR data server 12 forwards the information from the edited form to the 
EHIS server 50, step 626, where it is processed appropriately. The web server 42 
then returns the user to the previous PHP web page, step 608. 

30 By selecting the link associated with the block 236 (FIG. 2) the user may 

schedule a prequalified appointment in accordance with a process 700 illustrated in 
FIG. 7. Upon selecting the link, the web server 42 queries the shadow server 50 for a 
list of available appointments for the current user, step 702. Whether prequalified 
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appointments are available will depend on the existence of a scheduling ticket 
illustrated at 704. The scheduling ticket is provided by the shadow server 50 
responsive to input received from a care provider and specifies which providers are 
available, what procedures are required and dates and times that the appointment may 
5 be scheduled. If there are appointments available, step 706, the web server 42 updates 
the PHP web page with a listing of the appointments, step 708. At step 710, the user 
selects an appointment to schedule and, if necessary, provides additional information 
necessary to narrow the search for dates, times, etc. The user may also cancel the 
process at step 712, and web server 42 returns the user to the PHP web page. 

10 Otherwise, at step 714, the PHR data server 12 requests available appointments from 
a scheduling engine portion (not depicted) of the shadow server 50. If there are no 
appointments that meet the user specified criteria, step 716, the web server 42 updates 
the PHP web page, and the user is requested to enter revised information. Otherwise, 
at step 71 8 the web server 42 displays the list of available appointment times on the 

1 5 PHP web page. At step 720, the user selects an appointment, and the web server 42 
forwards the appointment selection to PHR data server 12, which places the request in 
the EHIS queue 16 for processing by the EHIS data server 14. When the appointment 
is booked, the updated appointment information flows via the shadow server 54 from 
the EHIS data server 14 to the web server, which updates the PHP web page with the 

20 selected appointment summary information, step 728. The web server 42 also 
updates the scheduling ticket to reflect that a prequalified appointment has been 
scheduled. The user may otherwise cancel the scheduled appointment at step 722 and 
be returned to the PHP web page. 

A second appointment option is initiated by selecting the link associated with 

25 block 238 (FIG. 2), which starts a process 800 illustrated in FIG. 8. After the user 
selects the link 238, the web server 42 queries the shadow server 50 for a list of 
available providers for the user, step 802. At step 804, the web server 42 updates the 
PHP web page with a list of the providers. At step 806, the user selects a provider 
and provides additional information, such as dates and times for the appointment. 

30 The user may also cancel, step 808, and the web server 42 returns the user to the PHP 
web page. Otherwise, at step 810 the PHR data server 12 requests available 
appointments information from the scheduling engine portion of the shadow server 
50. If there are no appointments within the date and time range provided by the user, 
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step 812, the web server 42 updates the PHP web page for the user to provide 
additional information. Otherwise, the web server 42 updates the PHP web page with 
a list of the available appointments, step 814. At step 816, the user selects an 
appointment or cancels the process, step 818. If an appointment is requested, the web 
5 server 42 forwards the appointment information to the PHR data server 12, which 
places the information in the EHIS queue 16 for processing by the EHIS data server 
14. When the appointment is booked, the updated appointment information flows via 
the shadow server 54 from the EHIS data server 14 to the web server, which updates 
the PHP web page with the selected appointment summary information, step 822. 

10 By the user selecting the link associated with block 240 (FIG. 2) a process 900 

illustrated in FIG. 9 is started that allows the user to enroll in a class. After the user 
selects the link 240, the web server 42 queries the shadow server 50 for a list of 
available classes for the user, step 902. At step 904, the web server 42 updates the 
PHP web page with a list of the classes. At step 906, the user selects a class or 

15 cancels the process, step 908. If the user cancels the process, the web server 42 

returns the user to the PHP web page. Otherwise, at step 910 the PHR data server 12 
requests available class times from the scheduling engine portion of the shadow 
server 50. At step 912, the web server 42 displays the list of available class times, 
and at step 914 the user selects a class time or cancels. If an appointment is requested, 

20 the web server 42 forwards the appointment information to the PHR data server 12, 
which places the information in the EHIS queue 16 for processing by the EHIS data 
server 14. When the appointment is booked, the updated appointment information 
flows via the shadow server 54 from the EHIS data server 14 to the web server, which 
updates the PHP web page with the selected appointment summary information, step 

25 920. If the process is cancelled, the web server 42 returns the user to the PHP web 
page. 

By selecting the link associated with the block 242 (FIG. 2) the user may 
initiate a process 1000 illustrated in FIG. 10 for paying a bill. The process 1000 
begins at step 1002 with the web server 42 making a query of the shadow server 50 
30 for accounts for the user. The web server 42 at step 1004 updates the PHP web page 
with an accounts listing. The user may select an account at step 1006, or may cancel, 
step 1008. If the user cancels, the web server 42 returns the user to the PHP web 
page, step 1010. If the user does select an account, at step 1012 a routine on the PHR 
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data server 12 requests information from an accounts receivable engine portion (not 
depicted) of the shadow server 50. The account is checked to determine if there is an 
outstanding balance, step 1014. The user may then return to the PHP web page 
providing the account listing. The user may elect to pay all or a portion of any 
5 balance due or may elect to pay ahead to develop an account credit toward an 
upcoming procedure. To permit the user to make a payment, the web server 42 
displays a pay online option for the account, step 1016. The user may click the pay 
online option, step 1018, and the web server updates the PHP web page with an 
online payment form, step 1020. The user completes the online payment form, step 
1 0 1 022, or the user may cancel the process, step 1 024 and be returned to the PHP web 
page. At step 1026, the web server 42 forward the information from the completed 
payment form to the PHR data server 12, which places the information in the EHIS 
queue 16 for processing by the EHIS data server 14. When the payment is processed 
by the EHIS data server, the information flows via the shadow server to the web 
1 5 server 42, which updates the PHP web page 38 with a message indicating that the 
payment has been submitted, step 1028. 

A rules-based scheduling system according to a preferred embodiment of the 
invention allows a facility to control appointments scheduled through the Internet, 
with "scheduling tickets" that incorporate a variety of rules and triggers. These rules 
20 can be defined as many things. Some examples that may be included are: 

(1) The type of patient. The system checks if the patient has any special 
conditions, such as being diabetic or undergoing cancer therapy, that would allow or 
disallow a patient to self-schedule. A clinic may not want certain patient types 
scheduling their own appointments because some patients need special consideration. 
25 (2) A patient's Insurance. The system checks to ensure that patients have 

insurance or other methods to cover their medical expenses. 

(3) Referral information. The system checks to ensure that patients do not 
have any outstanding referrals for that type of visit so that appointments are not 
duplicated. 

30 (4) Previous visits of a certain type. The system checks if patients are due for 

or require a follow up appointment. For example, a minor operation may warrant a 
return visit to remove the sutures. 
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(5) Provider preferences. The system takes into account when providers can 
or want to see certain types of patients. For example, if a provider does not want to 
schedule physicals in the morning, the system could reject any ticket submission from 
patients to have physicals scheduled in the morning for this particular provider. 
5 (6) Patient preferences. The system takes into account when patients want to 

be seen by their providers. 

(7) Past patient history. The system checks if factors exist that may change 
whether or not a patient can self-schedule. For instance, a system could deny a 
patient the right to self-schedule because he has a history of more than 20% no-shows 

10 or cancellations. 

(8) Copay requirements. The system checks if a copay by the patient is 
required for the appointment. Accordingly, the system requires that a patient must 
pay the copay when he or she schedules the appointment. 

These rules could further be set up as a layered hierarchy. They could be 
1 5 specified at various levels which include, but are not limited to: 

(1) System level or facility level. This is the least specific level. The settings 
at this level pertain to an entire healthcare facility. 

(2) Department level. This level is more specific than the system level. The 
settings at this level pertain to all providers who work in a specific department of a 

20 facility. 

(3) Provider level. This level is very specific. The settings at this level pertain 
to only a specific provider. 

(4) Rule level. The specificity of this level could vary, depending on how a 
facility has set up the system. For example, one facility could set up the rules level 

25 settings as overriding settings at the provider level, while another facility could set up 
settings at the provider level as overriding the settings at the rules level. The settings 
at this level pertain to only a specific rule. 

Rules set at more specific levels could override rules set at less-specific levels. 
For example, if an entire clinic's system is configured to allow diabetic patients to 

30 self-schedule using pre-authorized scheduling tickets, but a diabetic patient attempts 
to use a scheduling ticket to schedule an appointment in a department that does not 
allow diabetic patients to self-schedule, the patient would not be able to self-schedule 
in that department because the department level is more specific than the system 
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level, so it takes precedence. However, diabetic patients in departments that allow 
diabetic patients to use self-scheduling or in departments with no specific rules for 
diabetic patients could still schedule an appointment with a ticket. 

Different rules could also be set up to override other rules. For example, 
5 provider preference rules could be set up to override patient preference rules when a 
patient is using a scheduling ticket to make an appointment. Also, the past patient 
history rules could be defined to override all other rules, because if a patient abuses 
self-scheduling, a facility would most likely not want that patient to be scheduling 
appointments, regardless of what the other rules dictate. 

10 Furthermore, these rules can be dynamic in their ability to change over time. 

For example, the system could revoke a patient's ability to self-schedule if the patient 
abuses the system. Therefore, if a patient self-scheduled three appointments and did 
not show up for them, the system could automatically change the patient's status from 
"able to self schedule" to "unable to self schedule." 

15 While the invention is further described in terms of several preferred 

embodiments, it will be appreciated that the invention is not limited in scope to the 
embodiments herein described. Many modifications, alterations and additions may be 
made without departing from the fair scope of the invention. 

Referring to FIG. 1 1 of the drawings, a flow chart representation is shown of 

20 the path that the system would take when a patient attempted to schedule an 

appointment directly from the system. Through the system, a patient with access to 
self-scheduling can, either with a pre-authorized scheduling ticket or through a user 
initiated scheduling process, request an appointment with his or her clinic or provider. 
The self schedule request would then have to pass a series of checks, or rules, before 

25 it could be fulfilled. First, the system would run 1 104 a rules check to see 1 106 if the 
patient is authorized to self-schedule appointments. If the patient has the appropriate 
authorization, the system would then check 1 1 10 to see if a pre-authorized scheduling 
ticket existed for the patient. If one existed, the system would offer 1 1 14 the patient 
time slots that met the ticket requirements. 

30 If there were no pre-authorized tickets for the patient, he or she would enter an 

appointment search criteria manually 1 1 12. Then the system would verify that the 
patient was allowed to see the search results, whether the search results were obtained 
using the pre-authorized ticket or using search criteria initiated by the patient. The 
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patient would then select 11 18 an appointment to schedule. The system would 
perform 11 20 one last check to make sure the patient was allowed to schedule the 
appointment and that the appointment was still available, and then the appointment 
would be made 1 124. If the specific appointment that the patient was trying to book 
5 was unavailable, the patient would be prompted 1 1 12 to enter scheduling information 
manually, and the process would start over. 

Again, if the scheduling ticket or the responses from the user initiated 
scheduling process pass all of the appropriate security checks, the system then can 
present the patient with a list of solutions that match his or her request. After the 

1 0 patient selects an appointment 1 1 1 8, the system can perform 1 120 a final check to 
ensure that the patient is authorized to use the ticket to schedule the appointment and 
that the time slot is still available. If the request passes this security check, then the 
system can notify 1 124 the patient that he or she has successfully scheduled the 
appointment with his or her clinic or provider. If for any reason, a patient is not 

15 allowed to self-schedule, the system could be configured 1 108 to immediately give 
the patient the option to request an appointment, as opposed to actually scheduling 
one with a scheduling ticket. 

As explained above, a patient can self-schedule an appointment with his or her 
clinic or provider using either a pre-authorized scheduling ticket 1 1 14 or through a 

20 user initiated scheduling process 1 1 12. As shown in Figure 12, a pre-authorized 

scheduling ticket is an electronic ticket that is given to the patient via their electronic 
health record managed by their physician. This record is stored on a computer server 
and is referenced by the Internet based scheduling system to limit the patient's ability 
to schedule appointments to what is described 1204 by the ticket. 

25 An electronic database of scheduling tickets (also referred to as access tickets) 

would be created. Attributes 1204 of records in this database would include the 
healthcare provider who authorized the ticket, the services the ticket entitles the 
patient to schedule (e.g. one follow up visit within the next two months), and the 
patient identifier for the patient the ticket is for. The ticket also has an attribute that 

30 describes its current status (unused, appointment made, appointment completed). 

These pre-authorized scheduling tickets would be automatically created during 
the physician's documentation of a clinical encounter with the patient. Typically a 
doctor will document when a patient should return, in follow up of a problem (e.g. to 
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check on how well a medication is working to control the patient's blood pressure) or 
for a follow up procedure (e.g. suture removal). When initially created, the ticket's 
status is set to "unused." 

Referring again to FIG. 12, the flowchart illustrates the process by which a 
5 user logged in to his Patient Health Portal (PHP) Web Page can schedule an 
appointment that has been pre-qualified. When the user clicks the Schedule 
Appointment option, the Web Server queries 1202 the Scheduling Server to see if 
there are any pre-qualified appointments available for the current user. If there are, 
the Web Server updates 1208 the PHP Web Page with the available appointment 

10 information. The user can then select 1210 an appointment to schedule, and indicates 
date, time, and locations (selections may be limited by information in the Scheduling 
Ticket database). The Web Server then obtains 1214 appointment times available 
within the selected range and displays 1218 them, whereupon the user can either 
select a time, change the search, or cancel. When a user completes the appointment 

1 5 scheduling process, the Web Server notifies 1 224 the Scheduling Ticket database that 
the appointment has been scheduled and the ticket for the current user is updated 1226 
accordingly. The Scheduling Ticket database will then track whether the appointment 
has been cancelled or completed, and will update the corresponding pre-qualified 
appointment record accordingly. 

20 As previously mentioned, in addition to direct provider created tickets, 

patients may schedule an appointment through a user initiated scheduling process 
1112. An example of when this may be utilized is when a provider places a patient on 
a disease management protocol. These protocols might call for a patient to be seen 
with a certain frequency for specified types of visits. These protocols would 

25 automatically grant authority for the patients that conform to the limitations of the 
protocols. This process could be used independently or in combination with other 
insurance information available for the patient and represents the limitations that 
would be imposed on a patient self-scheduling through the web. 

To provide additional control for healthcare providers, the system may be 

30 designed to apply a more restricted set of rules to patients scheduling appointments 
through the user initiated scheduling process. For example, a healthcare provider may 
reserve only a few time slots per week for patients to schedule appointments through 
this process. They may additionally limit those appointments to very short durations 
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for limited purposes, such as consultations or the administration of simple tests. 
Another example is that the system could restrict a patient from selecting a provider 
or a department. Instead, the system would pick an appropriate provider or 
department from a pre-determined list that is driven by the patient as a parameter. 
5 The patient would be provided access to a self scheduling application (e.g. a 

web site or a computer application for personal use, possibly running on a home 
computer, personal digital assistant (PDA) or cellular telephone) which would allow 
them to schedule the appointment. 

This self-scheduling computer application would identify and authenticate the 

10 patient and read the database of electronic tickets to determine what self-scheduling 
limits exist for the patient. The self-scheduling application then allows the patient to 
select appointments that are within the limitation of the ticket. 

Once an appointment is made, it is associated with the ticket. The ticket is 
then marked as "appointment made." When the appointment is kept, the ticket is 

15 marked as "appointment completed" and then subsequently destroyed or retained for 
historical analysis. If the patient or provider cancels the appointment, the ticket's 
status would revert to the "unused status." 

The integration of the self-scheduling component into an overall healthcare 
management system is shown in Figure 13. A completely integrated system provides 

20 patients with secure, real-time access to their Personal Health Record and an 

Enterprise Health Information System (PHR and EHIS, respectively). Access may be 
provided by way of the Internet 316 and via a Personal Health Portal (PHP) web page 
1318. From the secure PHP web page 1318, patients can view information created 
and maintained by their health care providers and their affiliated staff. The patients 

25 can also request services and information from their health care providers and 
affiliated staff, directly access EHIS-related services, such as scheduling an 
appointment, paying a bill, enrolling in a class, completing insurance and other forms, 
and viewing information and Internet services that are relevant to their particular 
health status. 

30 In a preferred embodiment of the invention a patient health record data server 

1302, including a machine readable media having a data structure containing patient- 
created data, is coupled by an electronic network with a patient interface. The 
electronic network may be the Internet 1316 and the patient interface may be a 
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suitable Internet access device including a browser for supporting a personalized web 
page 1318. A secure interface securely couples, in real-time, the patient health record 
server 1 302 to an enterprise health record system 1 304 for providing access by the 
patient to patient-related data retained within the enterprise health record system 
5 1 304. Thus, the patient, via the patient interface, may access the patient health record 
server 1 302 for manipulating the patient-created data and for accessing the patient- 
related data from the enterprise health record system 1304. 

Referring again to Figure 13 of the drawings, the system includes a Patient 
Health Record (PHR) data server 1302, an EHIS data server 1306, and a self- 

1 0 scheduling server 1 308. The PHR data server 1 302 may be any suitable platform 
including processing, memory and data storage capability, to perform the functions 
herein described. The PHR data server 1302 stores data entered by the patient within 
a data structure configured within the storage portion of the PHR data server 1302. A 
secure interface or EHIS queue securely couples the PHR server 1302 and the EHIS 

15 data server 1306 for communication of data and information from the PHR data 
server 1302 to the EHIS data server 1306. The EHIS queue provides a real-time 
secure communication link for information moving from the PHR data server 1302 to 
the EHIS data server 1 306. This queue is used to transfer information for secure 
messaging and self-service options. In response to information received from the 

20 PHP web page 3 1 8, the PHR data server 1 302 forwards information to the EHIS . 
queue. Information in the EHIS queue is then processed appropriately by the EHIS 
data server 1306. 

While the specific configuration of the EHIS data server 1306 is not particular 
to the structure and function of the present invention, preferably, the EHIS data server 

25 1306 is a single data repository structured to support both the separation and the 
sharing of data. As such, the EHIS data server 1306 may receive information from 
existing outpatient and inpatient data management systems via interfaces or from 
various integrated applications. The EHIS data server 1306 may be configured to 
organize information into a consistent whole to provide a longitudinal patient record. 

30 For example, the EHIS data server 1306 may be linked to manage all aspects of a 
patient's hospital health status and care and to support effective management of 
patient lists, results inquiry management, complete clinical documentation, physician 
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order entry with decision support, nursing workflow and documentation, and 
discharge planning. 

The EHIS data server 1306 may further be configured to support the inclusion 
of problem lists, order communications, results reporting, pharmacy management, 
5 quick documentation, clinical messaging and communication. Additionally, the EHIS 
data server 1306 may be configured to manage refeiral information, up-to-date 
progress notes, lab results, discharge instructions, portions of a patient's record, and 
emergency summary cards. A suitable data management product that may be adapted 
as the EHIS data server 1 306 is the Epicenter^ Enterprise Data Repository and related 

10 suite of products available from Epic Systems Corporation of Madison, Wisconsin. 

The specific configuration of the scheduling server 308 is also not particular to 
the structure and function of the present invention. However, the scheduling server 
may be any suitable platform that includes a processor, memory and data storage 
capability to perform the functions herein described. These functions may 

15 alternatively be performed by the EHIS server 1306. Thus, the scheduling server 
1308 may be a separate component from the EHIS server 1306, or it may be one in 
the same. 

An electronic network couples the PHR data server 1302, the EHIS server 
1306, and the scheduling server 1308 to a patient interface. While Figure 1 3 depicts 

20 the scheduling server 1308 as a separate component, as mentioned above, an 

alternative embodiment may include the scheduling server as part of the EHIS server 
1306, as represented by the phantom line 1304 in Figure 13. The electronic network 
may include the Internet 1316 or another suitable data network. The system servers 
are electronically linked to the Internet by a web server 1312 in a highly secure dual 

25 firewall configuration. In this arrangement, a primary fire wall 1314 protects the web 
server 1312 and a secondary fire wall 1310 protects the PHR data server 1302, EHIS 
server 1306, and scheduling server 1308. Additionally, the PHR data server 1302, 
EHIS server 1306, and scheduling server 1308 are also electrically interconnected. 

Patients access the system by logging into the web server 1312 via the patient 

30 interface. The patient interface is preferably configured as a web page displayed 
within a web browser running on a suitable platform, and is further preferably 
configured as a personalized Personal Health Portal (PHP) web page 1318 providing 
the patient with patient-specific information and links to the features and services 
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ofFered by the invention. The web server 1312 may be any suitable web server 
platform containing routines for displaying the PHP web page 131 8 and for managing 
online communication between a user logged in via an associated PHP web page 
1318, the PHR data server 1302, and the EHIS data server 1306. 
5 Rules-based scheduling tickets solve the many problems that the healthcare 

industry has encountered. First, the scheduling ticket could be sent to the facility via 
a secure web-access application ensuring that the request will remain confidential. 
Furthermore, the self-scheduling functionality is equipped with a dynamic feedback 
system, which prevents patients from abusing their self-scheduling capabilities. For 

10 instance, if a patient schedules multiple appointments and does not show up for the 
appointments, the patient could be banned from scheduling any more appointments 
over the Internet. Finally, because of the hierarchical rules that a facility could enact, 
the facilities, departments, and providers are able to determine which patients can use 
scheduling tickets and which time slots they can schedule in at different levels, so that 

1 5 they do not lose control of their daily schedules. 

The invention has been described in terms of several preferred embodiments, 
including a number of features and functions. Not all features and functions are 
required for every embodiment of the invention, and in this manner the invention 
provides a flexible system by which a user may access patient records, send and 

20 receive messages, retrieve information, schedule appointments, renew prescriptions, 
pay bills and the like. The features discussed herein are intended to be illustrative of 
those features that may be implemented; however, such features should not be 
considered exhaustive of all possible features that may be implemented in a system 
configured in accordance with the preferred embodiments of the invention. 
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CLAIMS 

We claim: 

1 . A system for providing a patient with access to a patient health record for that 
patient, the system comprising: 

a patient health record server including a machine readable media having a 
data structure, the data structure containing patient-created data; 

a communication network coupling the patient health record server with a 
patient interface, the patient interface providing the patient with access to the patient 
health record server via the communication network; 

a secure interface adapted to securely couple in real-time the patient health 
record server to an enterprise health record system for providing access by the patient 
health record server to patient-related data for the patient retained within the 
enterprise health record system; 

wherein, via the patient interface, the patient may access the patient health 
record server for manipulating the patient-created data and for accessing the patient- 
related data from the enterprise health record system. 

2. The system of claim 1, wherein the communication network comprises the 
Internet and wherein the patient interface comprises a web browser. 

3. The system of claim 2, wherein the patient interface further comprises a 
personalized patient home page. 

4. The system of claim 1, wherein the secure interface is adapted for securely 
exchanging messages between the patient and the enterprise health record system. 

5. The system of claim 4, wherein the messages comprise messages of the type 
comprising: a request for medical advice; a request for prescription renewal; a request 
for a referral; a customer service request; a request for a pre-qualified appointment 
and a request for an appointment. 
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6. The system of claim 1, further comprising a shadow server coupled to the 
enterprise health record system, the shadow server including a machine readable 
media and wherein a copy of the patient-related data is retained on the shadow server, 
and 

wherein the communication network securely couples the patient interface to 
the shadow server for permitting viewing of the patient-related data by the patient. 

7. The system of claim 1, wherein the communication network comprises a 
security server, the security server being adapted to prohibit copying of the patient- 
created data or the patient related data from the respective patient health record server 
and the enterprise health record system. 

8. The system of claim 1 , wherein the communication network comprises a 
security server, the security server being adapted to prohibit unauthorized access to 
the patient-created data and the patient-related data via the communication network. 

9. The system of claim 1, adapted to receive a scheduling ticket from the 
enterprise health record system and the communicate the scheduling ticket to the 
patient, the scheduling ticket enabling the patient to schedule an appointment with a 
health care provider in accordance an authorization provided by the scheduling ticket. 

10. The system of claim 1, the patient health record server coupled to a source of 
information, the patient health record server including a relevancy engine for 
selecting patient-specific health-related information and for displaying that 
information to the patient via the patient interface. 

1 1 . The system of claim 1, the patient health record server adapted to receive 
payment information from the patient via the patient interface and to communicate the 
payment information to the enterprise health record system. 

12. The system of claim 1, wherein the secure interface is configured to provide 
view only access to the patient-related information. 
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1 3 . The system of claim 1 , wherein the patient-related information comprises one 
of the group of patient-related information types comprising: 

a medication list, a lab result, recent visit information, appointment 
information, immunization information, allergy information, a problem list, insurance 
information, account information, referrals information, administrative information, 
staff information, financial information, insurance information and messages. 

14. The system of claim 1, wherein the patient health record server is adapted to 
receive messages from the patient via the patient interface and to forward the 
messages to the enterprise health record system. 

1 5. The system of claim 14, wherein the messages comprises one of the group of 
message types comprising: 

an appointment request, a medical advice request, a medication renewal 
request, a customer service message and an address change. 

1 6. The system of claim 14, wherein the patient health record server is adapted to 
receive a self-service access authorization for a patient from the enterprise health 
record system and to forward the self-service access authorization to the patient via 
the patient interface. 

1 7. The system of claim 1 6, wherein the self-service access authorization 
comprises one of the group of self-service access authorization types comprising: 

an option to schedule an appointment, an option to enroll in a health education 
class and an option to make credit card payments. 

18. The system of claim 1 , wherein the patient-created data comprises one of 
unstructured information and structured information. 

1 9. The system of claim 1 , wherein the patient-created data comprises one of the 
group of data entry types comprising: 

a medication list, a health reminder list, a medical history summary, an 
immunizations list, an allergies list and a current health issues list. 
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20. The system of claim 1, wherein the patient-created data comprises one of 
clinical information and administrative information. 

21. The system of claim 1 , wherein the patient health record server is adapted to 
receive an information flag from the patient via the patient interface and to associate 
the information flag with one of the patient-created information and the patient- 
related information. 

22. The system of claim 2 1 , wherein the patient health record server is further 
adapted to send an alert to the enterprise health record system upon receipt of an 
information flag. 

23. A method of linking patients with a patient health record for that patient, the 
method comprising the steps of: 

within a patient health record server, providing a data structure containing 
patient-created data; 

coupling the patient health record server with a patient interface, the patient 
interface providing the patient with access to the patient health record server via the 
communication network; and 

securely coupling in real-time the patient health record server to an enterprise 
health record system for providing access by the patient health record server to 
patient-related data for the patient retained within the enterprise health record system. 

24. The method of claim 23, wherein the communication network comprises the 
Internet and wherein the patient interface comprises a web browser. 

25. The method of claim 24, wherein the patient interface further comprises a 
personalized patient home page. 

26. The method of claim 23, further comprising the step of securely exchanging 
messages between the patient and the enterprise health record system. 
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27. The method of claim 26, wherein the messages comprise messages of the type 
comprising: a request for medical advice; a request for prescription renewal; a request 
for a referral; a customer service request; a request for a pre-qualified appointment 
and a request for an appointment. 

28. The method of claim 23, further comprising the step of providing a shadow 
server coupled to the enterprise health record system and copying the patient-related 
data to the shadow server. 

29. The method of claim 23, further comprising the step of prohibiting the 
copying of the patient-created data or the patient related data from the respective 
patient health record server and the enterprise health record system. 

30. The method of claim 23, further comprising the step of prohibiting 
unauthorized access to the patient-created data and the patient-related data via the 
communication network. 

31. The method of claim 23, further comprising the steps of receiving a 
scheduling ticket from the enterprise health record system and communicating the 
scheduling ticket to the patient, wherein the scheduling ticket enables the patient to 
schedule an appointment with a health care provider in accordance an authorization 
provided by the scheduling ticket. 

32. The method of claim 23, further comprising the steps of providing patient- 
specific information to the patient via the patient interface. 

33. The method of claim 23, further comprising the steps of receiving payment 
information from the patient via the patient interface and communicating the payment 
information to the enterprise health record system. 

34. The method of claim 23, further comprising the steps of limiting information 
access to view only access of the patient-related information. 
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35. The method of claim 23, wherein the patient-related information comprises 
one of the group of patient-related information types comprising: 

a medication list, a lab result, recent visit information, appointment 
information, immunization information, allergy information, a problem list, insurance 
information, account information, referrals information, administrative information, 
staff information, financial information, insurance information, and messages. 

36. The method of claim 23, further comprising the steps of receiving messages 
from the patient via the patient interface and forwarding the messages to the 
enterprise health record system. 

37. The method of claim 36, wherein the messages comprises one of the group of 
message types comprising: 

an appointment request, a medical advice request, a medication renewal 
request, a customer service message and an address change. 

38. The method of claim 23 further comprising the steps of receiving a self- 
service access authorization for a patient from the enterprise health record system. 

39. The method of claim 38, wherein the self-service access authorization 
comprises one of the group of service request types comprising: 

an option to schedule an appointment, an option to enroll in a health education 
class and an option to make credit card payments. 

40. The method of claim 23, further comprising the steps of receiving patient- 
created data and linking the patient-created data to a corresponding data entry in the 
enterprise health record system. 

41 . The method of claim 40, wherein the corresponding data entry comprises one 
of the group of data entry types comprising: 

a medication list, a health reminder, a medical history summary, an 
immunizations list, an allergies list and a current health issues list. 
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42. The method of claim 23, further comprising the step of building a patient 
health record from the patient created data. 

43. The method of claim 23, further comprising the steps of receiving an 
information flag from the patient via the patient interface and associating the 
information flag with one of the patient-created information and the patient-related 
information. 

44. The method of claim 43, further comprising the step of sending an alert to the 
enterprise health record system upon receipt of an information flag. 

45. A method of self-scheduling appointments between service recipients and 
service providers via an electronic network, the method comprising the steps of: 

receiving via the electronic network an appointment scheduling request from a 
service recipient; 

determining an authorization of the service recipient to submit the 
appointment scheduling request; 

identifying a pre-authorized scheduling ticket for the service recipient, the pre- 
authorized scheduling ticket including appointment scheduling information; 

providing to the service recipient an appointment proposal in accordance with 
the appointment scheduling information; and 

applying a set of rules to the appointment request to determine if the requested 
appointment is allowed. 

46. The method of claim 45, wherein the set of rules comprises a rule selected 
from the group of rules including: type of patient, patient insurance, referral, provider 
preference, past patient history and copay requirements. 

47. The method of claim 45, wherein the set of rules comprises a hierarchy of 
rules. 
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48. The method of claim 47, wherein the hierarchy comprises a hierarchy selected 
from the group of hierarchical levels including: system or facility, department, 
provider and rule. 



49. The method of claim 45, wherein the set of rules is predetermined. 

50. The method of claim 45, wherein a rule of the set of rules is dynamic. 

5 1 . The method of claim 45, wherein the step of determining an authorization of 
the service recipient includes authorizing a user initiated scheduling process when a 
scheduling ticket is not located. 

52. The method of claim 5 1 , further comprising the step of applying a more 
restricted set of rules when an appointment is scheduled through the user initiated 
scheduling process. 

53. The method of claim 45, further comprising the step of verifying the pre- 
authorization scheduling ticket. 

54. The method of claim 53, wherein the step of verifying the pre-authorization 
scheduling ticket comprises checking at least one of the group of checks including: 
availability of self-scheduling for the service recipient, validity of the pre-authorized 
scheduling ticket, and availability of requested appointment slots. 

55. The method of claim 45, wherein the step of identifying a pre-authorized 
scheduling ticket for the service recipient comprises receiving the appointment 
scheduling information from the service provider. 
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56. A system to allow self-scheduling of appointments via an electronic 
network, the electronic network configured to permit secure access thereto by 
a service recipient, the system comprising: 

a self-scheduling server coupled to the electronic network for secure 
communications therewith, the self-scheduling server adapted to receive 
appointment scheduling requests from the service recipient securely via the 
electronic network; 

a self-scheduling server including a processor, the processor being 
coupled to a rule base, to a scheduling database, and to receive the 
appointment scheduling request; and 

wherein the processor is operable upon the appointment scheduling 
requests to authorize the appointment scheduling request, to send appointment 
schedule information to the scheduling database for inclusion therein and to 
send an appointment acknowledgment to the service recipient securely via the 
electronic network. 

57. The system of claim 56, wherein the scheduling database includes pre- 
authorization scheduling information associated with the service recipient. 

58. The system of claim 57, wherein the pre-authorization scheduling 
information comprises a pre-authorized scheduling ticket. 

59. The system of claim 58, wherein the pre-authorization scheduling 
ticket is automatically generated within the scheduling database. 

60. The system of claim 56, wherein the scheduling database includes 
information associated with the service recipient is manually entered through a 
user initiated scheduling process. 

61 . The system of claim 56, wherein the system is part of an enterprise 
healthcare information management system. 
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62. The system of claim 56, wherein the rule base contains a set of rules. 

63. The system of claim 62, wherein the set of rules comprises the group 
of rules including: type of patient, patient insurance, referral, provider 
preference, past patient history and copay requirements. 

64. The system of claim 62, wherein the set of rules comprises a hierarchy 
of rules. 

65. The system of claim 64, wherein the hierarchy of rules comprises the 
group of hierarchical levels including: system or facility, department, provider 
and rule. 

66. The system of claim 56, wherein the set of rules is predetermined. 

67. The system of claim 56, wherein a rule of the set of rules is dynamic. 
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